feat(workflows): add gh release instead of ncipollo/release-action#1392
feat(workflows): add gh release instead of ncipollo/release-action#1392seifertm merged 4 commits intopytest-dev:mainfrom
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1392 +/- ##
=======================================
Coverage 95.13% 95.13%
=======================================
Files 2 2
Lines 473 473
Branches 57 57
=======================================
Hits 450 450
Misses 17 17
Partials 6 6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
dzhalaevd
changed the title
dzhalaevd
left a comment
dzhalaevd
left a comment
There was a problem hiding this comment.
I think this is ready for review
seifertm
left a comment
seifertm
left a comment
There was a problem hiding this comment.
First of all, thanks for the initiative of solving this!
I think I understand what process you're aiming for, but we can keep it simpler. Releases are always created from a specific commit hash/tag. If the build is reproducible, the same commit will always lead to the same release artifacts. Therefore, there's no reason to foresee a release being updated or changed.
That means, if a release for a tag is already present, we do nothing. Otherwise, we create a new release. No need to update existing releases.
dzhalaevd
force-pushed
the
1382-remove-ncipollo-deps
branch
from
22e01aa to
5d3fed3
Compare
* remove `changed` file * simplify main.yaml * replace VERSION to TAG_NAME in title Co-authored-by: Michael Seifert <m.seifert@digitalernachschub.de>
dzhalaevd
force-pushed
the
1382-remove-ncipollo-deps
branch
from
5d3fed3 to
f3278d7
Compare
3 participants
What was wrong?
Due to security issues with
ncipollo/release-actionneed to remove this dependency and replace withgh releaseCloses: #1382
Related: #1382
How it was fixed?
The release logic previously implemented via
ncipollo/release-actionhas been reimplemented using theghOur workflow now relied on two key flags:
allowUpdates: trueskipIfReleaseExists: trueThese flags overlap in behavior at least semantically and the ncipollo documentation doesn't clearly define their interaction or precedence. Based on the existing workflow, i was reimplemented as follows with this idea:
I tried run jobs for check how release creating here
and re-run for checking how it was updates